研发笔记 - 支持TiDB的背后故事和思考
Bytebase是一款聚焦在数据库schema变更的开源产品。在已有的版本中，我们已经支持了MySQL。而理论上，只要是有schema的数据库产品，都是属于Bytebase潜在可以支持的对象。而TiDB是来自PingCAP的一款开源，云原生，分布式数据库。因为TiDB兼容了MySQL协议，所以Bytebase在经过了一些适配后，也在0.6.0版提供了对于他的原生支持。
当然在整个功能的研发过程中，还是有不少插曲，所以写一篇笔记记录一下。
序幕
其实支持TiDB本不在近期Bytebase的开发计划内，本来我们打算先支持PostgreSQL。不过上周正好遇见了TiDB的小伙伴，互相交流了一下产品。还让TiDB的同学尝试用之前版本的Bytebase连一下TiDB，可惜现场翻车。但在观摩过程中，发现TiDB有一个TiUP的命令行，可以快速本地启动一个TiDB实例。有这个工具在的话，就能快速搭建测试环境，所以就打算回去认真试一下（当然也是为了挽尊）。
研发过程
引擎适配
TiUP确实不负众望，在我们的研发环境中也快速启动了。因为兼容MySQL协议的关系，我们还是复用了之前用于支持MySQL的代码。适配中碰到了这么几个和原生MySQL不一样的点:
INFORMATION_SCHEMA.TABLES.TABLE_COLLATION 应该是Empty string而不是NULL。另外估计TABLE_COLLATION这个定义是NOT NULL，导致NULLIF判断也出了问题。这个Bug已经提交给了社区，看进度已经有人在解决了。
TiDB不支持开启readonly connection。
如果在一个Transaction内有CREATE DATABASE db1接着再来一条CREATE TABLE db1.tb1的话，TiDB会报错说找不到db1，而MySQL不会报错。不过这里的处理确实复杂一些, MySQL本身也只支持单DDL的transaction。
系统库里多了一个METRICS_SCHEMA。
原生MySQL从information_schema里返回的系统库名，返回值是小写，比如information_schema，而TiDB返回的是大写INFORMATION_SCHEMA。
创建Bytebase schema的完成速度要比MySQL慢不少，本地需要几秒钟的样子。
所幸碰到的这些问题都有workaround，整体上TiDB的MySQL兼容性做的还是不错的，没有致命的问题，所以还是很顺利地就完成了引擎层的适配工作。
UI适配
首先是在创建Instance时提供了选择不同数据库的选项，同时默认Port也设为了TiDB的4000端口
在创建后的实例页面也加了数据库Logo
还有列表页
当然也包括Issue详情页
同样在Demo数据上也添加了，这样用户可以快速识别到我们支持的数据库类型。
研发回顾
贴合用户
TiDB作为一款数据库引擎，是有两拨用户，一拨就是日常使用数据库的用户，还有一拨就是包括Bytebase这样给TiDB提供工具的用户。对于后一拨用户来说，首先要解决的是能让他们的接入成本尽量的小。促使Bytebase尝试去接入TiDB的主要原因有2个，首先他兼容的是MySQL协议，Bytebase已经开发了适配MySQL的代码。另外一个很重要的就是有TiUP这款一条命令行拉起TiDB的工具，可以让Bytebase在研发过程中快速搭起完整的开发环境。如果没有TiUP的话，Bytebase也是不太会冒险尝试接入的，因为无论是开发过程，还是后续用户碰到问题，需要复现都会有相当高的成本。这其实也是为什么Bytebase决定暂时只支持TiDB 5.0的原因，因为TiUP只提供了5.0的版本
兼容性
为了贴合用户，往往新的数据库都会选择支持MySQL协议或者PostgreSQL协议。但要做到100%兼容几乎是不可能的事情，因为不仅是要功能兼容，还要做到Bug兼容。所以与其要去做100%兼容，更实际的方案是不要有致命的问题，比如某个字段类型不支持这种。而在遇到兼容性问题时，引擎可以返回可读的错误，这样用户能通过搜索引擎，精确定位到相关资料，自助解决。在这方面，TiDB做的也不错，比如碰到的那个不支持readonly connection的问题，能抛出定制化的错误信息，方便下一步行动（当然readonly这个功能对于数据库还是挺重要的，是额外的一层safe guard，希望可以在TiDB将来的版本中支持上）。
代码的鲁棒性
在对接新系统的过程中，也暴露了Bytebase本身的一些鲁棒性问题，比如创建schema慢了，导致请求超时。比如大小写没有考虑。这些是属于工程纪律的范畴，Bytebase当前也有一套api的规范做了统一，随着Bytebase的模块越来越多，统一性规范的价值也越来越大。
观察用户
最开始在观察TiDB小伙伴使用Bytebase的过程中，光在创建Instance页面，就发现了3，4个UX的问题。所以许多时候也不需要什么设计方法论，最高效的方法，就是让程序员/设计师/产品经理坐在用户旁边，默默看她如何使用产品。
对于TiDB的印象
说起来从TiDB诞生之初，我们团队就开始关注了，不过这次还是第一次近距离的接触。从开发者角度来说，综合体验还是不错的，无论是TiUP这个小神器，文档的准确度，还是社区的反馈速度。从工具开发商的角度，我们还想提2个小建议:
可以参考GitLab，GitHub这种，提供一套可从官网下载的logo标志。这样我们不需要从其他地方找Logo，放到产品里。
TiDB的版本已经挺多了，但官网上还没有明确的维护周期策略。这个可以给工具商一个很明确的指引，产品应该支持哪些版本。
当然瑕不掩瑜，总体上这次的接入比预想中要顺利的多，也侧面体现了TiDB在产品化方面的成熟度。另外TiDB还开源了他们兼容MySQL的Parser, Bytebase得以基于此在这次的版本中添加了语法检查的功能。后续我们也打算基于他开发更高级的SQL Advisor能力。
最后
好了，大家有兴趣的话，欢迎去https://github.com/bytebase/bytebase下载最新版体验，点击「阅读原文」直达。后续我们也会分享其他研发过程中的故事和思考。
最后让我们举杯Thai tea，共邀明月。